I don't see the benefit of the double check under lock especially since we expect frame-to-frame the mappings wont actually change. Why not just lock and check once? I feel that would be faster here.

I've pointed it out before, but get_system_time is unreasonably heavy. Prefer TSC unless real-world precise values are required.

A general note - the spu_info logic (test_and_update_atomic_op_info) in general is quite heavy-handed with all the atomic ops and may eat into performance. The biggest issue I see is that there is no fast-path through this calling sequence (and the corresponding one below). Yes, spurs itself is going to be almost always running task groups but we also observe that in most games the parallel misses themselves aren't too bad with modern processors, though I agree we need something more sophisticated than the quick hack that was the preferred threads option.
This is all theory of course, we'll just have to see if it ends up worth the overhead with the big hitters like RDR, TLOU or killzone titles.

I think we can abuse vector ops for this sequence and gain implicit atomicity.
Have the spu info as an object of arrays instead of array of objects.
Then you can just load all of them at once and (ab)use vector ops on the vector to figure out how much overlap there is.

On x86 at least, vector ops are atomic as long as they are naturally aligned too so we basically get that for free.

Why is this change needed?
Zero comments

We shouldn't touch VM memory under mutex for few reasons. (RSX access violations lengthens the duration of the lock for example)
We can put it in the coding guidelines.
There is no need to comment it each time.

Then a wrapper construct makes more sense, otherwise it will be repeated again elsewhere. Or maybe unlocked probe_for_read / probe_for_write makes more sense like usually done in real drivers.